Category: Geeks r Us
Hello all,
For those of you who just feel like hacking at some code, or whatever your case may be, I'm announcing my half-complete mud engine here.
Aspen was written to give people a light-weight, easy to use flexable barebones engine from which they can build everything from the ground up. It's currently about 8000 lines of code (not overly huge), but it has a lot of work to be done. If you are good with c++ or just want to play with it, I would love your ideas, comments, suggestions and contributions.
Aspen currently supports:
Easy serialization, with a hierarchical object setup.
Rooms and zones (partially complete, still needs some work).
A module system, which allows users to add modules specific to their game without having to hack at the core of the mud.
This is especially nice in mud engines because those who use circle end up finding themselves living with pre-existing systems or ripping them out, which leads to lots of unused code laying around, as well as the potential for security issues and makes things a lot messier.
A channels system, which integrates with the command API.
An event system.
Each system so far has it's own defined API, with the world class being the main point for management. While I do plan on doing some redesign, I think I like the overall feel of Aspen thus far.
Aspen has some of the following left to do.
A help system (one existed), but I tossed it the other day; I was kind of ashamed to claim that code as my own.
scripting: Aspen uses Lua as it's scripting system, and while I have started work on the interface, framework, and some of the actual scripting mechenisms, there still remains lots of work left.
Serialization: I want to convert Serialization to xml.
Rooms, zones, commands for building, and adding content also need to be set up.
Documentation: while I have documented most of my code (the functions in the header files, mainly and not the actual body of the functions), documentation is a huge plus; essentially, I or someone else just needs to add tags so that it will work with Doxygen. This is something someone with Minimal programming knowledge could do, and if someone would help out with that, you'd be my hero for the year.
As always, comments, suggestions and the like would be awesome.
I can be contacted at:
aim: st8amnd2005
msn: tyler@tysdomain.com
(also functions as email)
skype: st8amnd127
And the project can be found at:
http://code.google.com/p/aspenmud
Happy hacking!
In the spirit of being lightweight on the implementation, take a poke around the net at XQuery as an implementation for pulling records from xml structures. Works nice in that it's a fragment language, and works on blobs or complete documents, depending on your implementations. There are open-source C++ and java-based implementations for you to use or harvest from.
Less overhead than, say, PHP / SOAP.
Certainly LUA has a lot of really nice ways of handling things, especially for a scripting language that can either run stand-alone script applications / extensions or scriptlets.
Consider the following as sort of a flyover view, touting a Java implementation but you'll know if you can make it a fit using a C library from Sourceforge or someplace.
http://www.ibm.com/developerworks/xml/library/x-xjavaxquery/
This is looking promising, and can't wait to test it when it's all ready to go.
Hello,
Thanks for the info. I'm using TinyXml; it has a small footprint and it is fairly light-weight, as far as XML libraries go. As I write this, I'm in the process of writing out the serialization to use that. I switched from a mapping-based property setup to a property tree, so I can just recurse through it and it works out great. As everything will be stored on properties, I could even just use a quick macro to serialize individual objects or entities/collections of objects.
The serialization for the property tree ends up looking something like this:
void Serialize(TiXmlElement *root)
{
std::vector<Property*::iterator it;
std::vector<Property*>::iterator itEnd;
TiXmlElement prop = new TiXmlElement("property");
prop->SetAttribute("name", Name);
Value.Serialize(prop);
if (Children.size())
{
it= Children.begin();
itEnd = Children.end();
for (; it != itEnd; ++it)
{
(*it)->Serialize(prop);
}
root.LinkEndChild(prop);
}
}
So essentially it just recurses (I should actually set a recursion limit, but the setup only goes as far as depth 1:
stats.hp.
stats.health.hp wouldn't actually work, so I guess I'll worry about that if I ever allow more. Essentially the only issue (as is with any recursion) is the problem of hitting the stack limit, but that's easy enough to add in.
I'll be sure to post more here once it's open. I plan to build a mud off of it, so that will be in the works, as well.
On a side note, after the serialization and a few more big changes I'm finishing off, I'd thought about building a miriani-like space system, which will serve a duel purpose:
1) It will allow me to have a proof-of-concept to make sure that the game and the base can handle something like this, and make changes so that the system can be fully component based,
2) and it will also allow people to see a fully developed system that they can play with and use for examples.
uh huh. vip mud rocks.
1) Aspen is a mud engine, (server), VIP is a client.
2) VIP mud does -not- rock. You pay $30 because people can't install a plugin for mush, and you get about a quarter of the features mush gives you, and mush is free.
Anyway, Aspen has nothing to do with whether or not VIP sucks...
Munkey turm is free not supported much any more but heck it works and "if its not broke don't fix it."
One point of clarification: The last two or three posts are talking about Mud Clients.
This is a MUDD Engine,not even a MUDD game though the creator may choose to make one as a prototype.
The client communicates with the engine which loads the game, and the user plays the game by sending commands to the game through the engine.
Short version of how it works.